Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Wireless Networking Handbook
(Publisher: Macmillan Computer Publishing)
Author(s): Jim Geier
ISBN: 156205631x
Publication Date: 09/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Documenting Requirements

To adequately support the remaining phases of the project, be sure to clearly document the requirements. Without good documentation, requirements can become unclear as time passes and memories lapse. The handover of project information from person to person can also dilute original intentions. To make matters worse, the analysts responsible for defining the requirements could leave and be unavailable during the design phase. Undocumented requirements also make it too easy for changes to occur in an uncoordinated fashion during later stages of the project, making it difficult to find the correct solution.

Therefore, the team should develop a requirements document containing, as a minimum, an illustration of the organization’s high-level business processes (in other words, how the company or applicable organization(s) operates) and definition of each requirement type. The following list shows the major elements of a requirements document:

  Requirement overview
  Specific requirements
  Constraints
  Assumptions
  Information elicitation methods
  Issues

To produce this document, the team should refer to all information gathered, such as interview and JAD meeting notes, regulations, facility evaluations, and prototypes.

Verifying and Validating Requirements

The importance of requirements can’t be overstated—inaccurate requirements lead to solutions that don’t adequately support the needs of the users. Thus, the project team should verify and validate the requirements. Verification checks if the requirements are accurate based on those needs. Validation proves whether the requirements fully represent the needs of the users and conform to the company’s business processes. Therefore, these two quality control tests answer these questions:

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”

Verifying Requirements

It’s best to verify requirements first, and then validate them. You want to be sure the requirements are okay before testing whether they meet user needs. The most important verification point is to be sure the requirements are complete and unambiguous. Complete requirements describe all aspects of the needs of the users and organization. For example, incomplete requirements might state needs for users and existing systems, but not identify anything about the environment, such as the presence of potential electromagnetic interference. For wireline systems, this might not be critical, but it could have serious impact on the operation of radio-based products. Requirements should be unambiguous to avoid needing clarification later. Ambiguous requirements force the designer to seek the finer details. To save time, most designers will guess the values of the remaining details, causing the designer to choose inappropriate characteristics.

For most projects, you can verify the requirements by referring to the requirements document and answering these questions:

  Do the requirements address all user and organizational needs?
  Do the requirements clearly state the needs?
  Do the requirements avoid describing solutions to the requirements?

Validating Requirements

The best method to validate requirements is to build a prototype as a model that represents the requirements. For application development, you can build a software prototype using a fourth-generation language, such as Powersoft’s Powerbuilder, that contains the screens and some functionality to implement the requirements. For off-the-shelf applications and hardware, of course, vendors normally allow enough evaluation time—one or two months—to test the application. For either case, you can have the users exercise the prototype and observe whether their needs will be met.

Baselining Requirements

The baselining, or standardizing, of requirements involves final documenting and approval of the requirements. This process makes the requirements “official,” and you should only change them by following an agreed-upon process. Who approves the requirements? Ultimately, the customer representative should give the final sign-off; however, an analyst should endorse the requirements in terms of their accuracy and efficacy. If you’re deploying the system under a contract, other people, such as the project manager and contract official, may also need to offer approvals. Be certain to indicate that both the organization and modification team consider the set of requirements as a firm baseline from which to design the network.

Updating the Project Plan

After defining the requirements, it’s time to revisit the planning elements you prepared earlier in the project. At first, you probably based the project WBS, schedule, and budget on incomplete and assumed requirements. The actual requirements, though, might cast the project in a different light. For example, maybe you found during the user interviews that information security was more important than you had expected. This might create a need to modify the WBS—and possibly the schedule and budget—to research security technologies and products. Or you might have planned to spend three weeks during installation setting up 150 computers, but during the interviews, you found there will only be 75. This information could enable you to cut back the schedule, or reallocate the time to a task that might take longer than expected.

With an updated project plan and final requirements, the project team is ready to move into the design phase of the project.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.